fix: fail Deployment tracking fast on ReplicaSet pod-create errors - #399

This PR makes the Deployment tracker fail fast on ReplicaSet pod-create errors such as FailedCreate ... exceeded quota, instead of hanging until the timeout.

The ReplicaSet controller reports pod-create failures on the ReplicaSet — a FailedCreate Warning event and a durable ReplicaSetReplicaFailure condition — while the deployment tracker only watched the Deployment object and its events, so these failures were never observed. StatefulSet and DaemonSet are unaffected because their controllers report FailedCreate on the object kubedog already watches.

fix: fail Deployment tracking on ReplicaSet pod-create errors

• Read FailedCreate from the durable ReplicaSetReplicaFailure condition of the Deployment's ReplicaSets instead of transient Warning events: the condition is set while pod creation keeps failing and removed once it succeeds, so failures that predate informer startup terminate tracking immediately and no event baseline is needed. Also works with KUBEDOG_DISABLE_EVENTS=1.
• Only ReplicaSets controlled by the tracked Deployment are considered: label selectors are not unique, so selector matching alone could pick up foreign ReplicaSets.

fix: handle ReplicaSet failure transitions consistently

• Forced Failed payloads set IsFailed and clear IsReady; lagging FailedCreate conditions after the Deployment becomes ready are ignored.
• Failures are deduplicated per ReplicaSet incarnation — by UID, since FailedCreate messages carry volatile quota numbers — and rearmed after condition recovery or Deployment readiness, so a failure that recurs is reported again.
• Stale informer replays of deleted ReplicaSets are ignored (UIDs are never reused), and deleting a ReplicaSet re-evaluates the new one: the deletion may promote a template-equivalent successor that is already failing, and its failure would otherwise never be reported.
• ReplicaSet events are delivered over unbuffered channels: additions, modifications and deletions come from a single informer goroutine but fan out into three channels, so buffering let the tracker apply an older event after a newer one and overwrite a fresh snapshot with a stale one. The informer stops sending once the consumer is gone, so a parked send cannot wedge the shared informer goroutine (regression-tested).
• Reported failures carry a FailureMode: failures coming from events stay counted against the allowed-failures budget, while a durable ReplicaSet ReplicaFailure condition is fatal — the dynamic readiness tracker marks the resource failed, so a single pod-create error terminates tracking instead of being swallowed by the default failures allowance. Fail modes that are not supposed to fail the deploy process (IgnoreAndContinueDeployProcess) are unaffected.

Verification: go build ./..., go vet ./..., go test ./..., including new lifecycle tests for the failure transitions (dedupe, rearm, stale events, successor promotion) over fake clientsets, -race runs on the deployment/replicaset packages, and a regression test that proves the informer goroutine is released after cleanup. Originally reproduced on a kind cluster (namespace with ResourceQuota pods: 0, 1-replica Deployment): tracking hung for the full timeout before the fix and fails within seconds with the FailedCreate quota message after it.

Closes #398
Refs #216, #363